This page last changed on Apr 10, 2007 by stepheneb.

What are the possibilities for getting more computational power for MW by creating local grids?

It is moderately straightforward. Normally it requires the attention at some point of a knowledgeable user/admin to install or setup software on all the computers used in the grid. So deployment to typical school environments is limited by the availability by this kind of person and of course whether the school technical policies and implementation even allow these changes.

A gain of 10x in horsepower would be most valuable 100x would be even better. In a typical computer lab, the computers are idling most of the time, but during a MW run, which might last only 10-20 sec, it would be wonderful to be able to recruit all local computers and/or a local server.

One possibility is the Java Grid Engine: http://gridengine.sunsource.net/

QX: Java World 3/28/2007 article on Java grid computing using the Globus API.

Another option is Apple's Xgrid. Of course Apple has made the setup dead simple (if you don't have a copy of MacOS Server it takes a bit more work to setup the grid controller). Here's a good article about the Xgrid technology: Distributed Tiger: Xgrid Comes of Age, by Drew McCormack, 08/23/2005.

There appears to also be a Java client which would allow any computer that ran Java to be an Xgrid node:

Here's an ACM article: Building computational grids with apple's Xgrid middleware (pdf).

From the ACM article:

8.6 XgridAgent-Java XgridAgent-Java (Campbell, 2005) is a pure Java Agent for Xgrid written entirely in Java. The primary motivation of this pro ject is to provide a plat- form independent Xgrid agent, allowing for heteroge- nous Xgrid clusters to be deployed. XgridAgent-Java utilises a number of open source components includ- ing JmDNS (van Hoff and Blair, 2005), BEEPCore- Java (Franklin, 2005) and Base64 (Brower, 2005). XgridAgent-Java supports dynamic resolution of an Xgrid cluster controller via a range of Apple sup- ported resource discovery services (either ZeroConf or Rendezvous or Bonjour), all via JmDNS. BEEPCore- Java is used to handle the BEEP layer of the Xgrid protocol. Base64 is used to handle binary elements in the Apple XML plist layer of the protocol.

XGrid Wiki: http://packmug.ncsu.edu/wolfgrid/XGridWiki/pmwiki/pmwiki.php

XGrid agent for Unix architectures: http://unu.novajo.ca/simple/archives/000026.html

Does J2EE support this? Is there a small proposal here???

Sure: if you can make a good argument for the pedagogic value in the delivery of more powerful dynamically constructed model simulations than can be done on one computer. I'll bet this is an easy argument to make. I've wanted to do computational fluid dynamics (see message from 3/8/07 subj: ideas for ALT/Computational Fluid Dynamics).

IN the modeling situations you envision what is the computational load breakdown between model computation and visual rendering?

QX: It looks like that we have two types of programs to be installed on a machine: agents and clients. An agent performs a task the controller assigns to it. It does not have a GUI and typically should run only when a computer is idle.

A client has a GUI that can be used to view and control an entire model being computed on a grid of agents. The full results have to be assembled by the controller and sent to the client 20-30 times per second. By using Jmol, we can probably achieve that FPS rate for 5,000 atoms on a single computer, given the CPU power left by RMI/RPC calls to update the system's state.

A client should probably not be an agent at the same time, because in a real-time situation the state updates through RMI/RPC and the visual rendering would keep the computer where the client resides too busy to spare CPU cycles for an agent.

More Xgrid Links

Document generated by Confluence on Jan 27, 2014 16:56